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BACKGROUND 

Field of the Invention 

[0001] The present invention is directed to the management of telephone systems. 

More particularly, the present invention is directed to systems and methods for 
assisting in the management of several telephone network systems, devices and 
equipment. Even more particularly, the present invention is directed to assisting a 
loop capacity manager in managing specific telephone network capacities and 
equipment; the invention is also directed to identifying locations for marketing where 
certain service types are available in a shorter interval. 
Background of the Invention 

[0002] Telephone facilities are managed using a cable name and a pair range. This 

method originated in the days when the only facility was a copper cable which 
originated at the Central Office (CO). The cable leaving the CO to the north might be 
called cable 1, the cable to the east might be cable 2, and so on. Cable 1 might have 
1800 pairs, thus it is denoted as 1: 1-1800 (or 1, 1-1800.) A customer's telephone 
number can then be reported as working on a particular pair such as 2: 27. 

[0003] As facility types have expanded to include digital loop carrier (DLC), fiber 

optic cables, and multiplexers, telephone companies have continued to use the same 
notation. In these cases, an attempt is made to logically name the cable. The first 
DLC systems were manufactured by Pair Gain, Inc., thus the naming convention for 
DLC systems of PG. For example, the first DLC system in a CO might be PGIO, 1- 
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100 (a pair gain system can provide 96 lines, so the notation typically uses a range of 
1-100 for the sake of simplicity .) Multiplexers are used in the local loop to convert 
fiber optic signals to DS-1 copper services. These DS-1 facilities are managed with a 
cable name of MD for multiplexer derived and an appropriate pair range. 

[0004] More specifically. Figure 1 depicts a typical telephone network including a 

first central office 10 that is connected, via connection pathway 1 1, to a second 
central office 12. Communication pathway 11 is of a known character and might 
comprise copper cable, fiber optic cable or radio firequency connectivity, or 
combinations of these mediums. Central office 12 (and likely 10, as well) includes a 
multiplexer/demultiplexer (MUX) 15 such as an OC-3 multiplexer or MUX, which 
might be operable to, for example, convert 3 DS-3 service lines into 84 T-1 or 84 DS- 
1 service lines, and vice versa. 

[0005] MUX 15 is typically connected, via fiber optic cable 17, to a remote terminal 

(RT) 20 that houses a digital loop carrier (DLC) system or pair gain (PG) device 22 
that is operable to convert DS-1 service levels to DS-0 service levels. Commercially- 
available pair gain devices are, for example, operable to convert between 4 DS-1 
service lines and 96 DS-0 service lines. 

[0006] The resulting individual DS-0 lines are typically connected, or fed, to a cross 

connect or cross box 25, via a feeder cable 24 that includes a plurality of copper pairs. 
In a typical telephone network, cable 24 might have anywhere firom 1-1800 pairs of 
twenty-two, twenty-four or twenty-six gauge twisted pair copper wire. 

[0007] The other side of cross box 25 (the right side in Figure 1) is connected to a 

distribution cable 27, which also includes a plurality of copper wire pairs that are 

2 



used, respectively, to service individual customers 30a, 30b, 30c, 30d. Some 
customers 30 will have the need for several telephone lines to furnish combinations 
of, e.g., telephone service, computer modems, fax machines, ISDN, Tl, ADSL, etc. 
Such customers will thus require more that one twisted pair of copper wire. Cross 
box 25 is thus used to connect customer lines 29a, 29b, 29c, 29d to the appropriate 
DS-0 service line made available via feeder cable 24. 
[0008] In many cases central office 12 can be connected directly to cross box 25 via 

copper cable 32, thereby bypassing a separate remote terminal. In such a case, the 
central office itself might include the fianctionality of the remote terminal including 
the pair gain device. 

[0009] As can be readily appreciated by those skilled in the art, managing the 

network and equipment shown in Figure 1 and described above can be daunting. 
Typically, a loop capacity manager (LCM), i.e., the manager responsible for the 
"local loop," is responsible for (i) keeping track of network capacities, equipment 
capacities and physical plant, (ii) determining whether bottlenecks are occurring or 
whether shortages are about to occur and (iii) proposing or preparing a plan of action 
for alleviating any such bottlenecks or shortages. 

[001 0] Telcordia, Morristown, NJ, is one manufacturer of telecommunications 

management software that captures various pieces of information that describe the 
several aspects of the local loop in an attempt to aid LCMs in managing the telephone 
network. One Telcordia product, commonly known as LFACS (Loop Facility 
Assignment Control System), which is used by most of the regional bell operating 
companies (RBOCs), fiinctions as a database of record for all local loop services by 
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storing information about each of the service levels in the local loop including direct 
customer DS-1 service, "plain old telephone service (POTS)," and even party line 
service that still may be available in rural areas. 

[001 1 ] Hovi^ever, LFACS, by itself is limited in its ability to provide all of the 

information that may be necessary for an LCM to effectively manage the local loop. 
Specifically, LFACS includes only assignment data in the form of cable name and 
pair range. There is no information in LFACS that describes equipment. 

[0012] To keep track of equipment, such as MUX's, SLCs and DLCs, RBOCs 

maintain several databases that capture equipment information. However, such 
databases typically do not also contain assignment data. That is, although an LCM 
might have access to both a database such as LFACS and another database that stores 
equipment information, the two databases are not tied together in any meaningful 
way. Indeed, it is often the case such databases are maintained by different entities, 
which causes the databases to be inconsistent with respect to each other. 
Accordingly, it is very difficult for an LCM to take advantage of the available 
information to conduct his local loop management fiinction. 

[001 3] In addition to the foregoing, the desire for increased bandwidth has 

skyrocketed in the past decade. This has resulted in customers gaining direct access 
to DS-l/T-1 and higher data rate service lines, rather than only DS-0 service lines. 
As a result, LCMs have also been recently tasked with managing these lines as well. 

[0014] Further, Digital Service Line (DSL) demand has also increased significantly 

in the past several years. Tracking and managing DSL usage is also typically the 



responsibility of the LCM. However, current management tools are insufficient for 
managing ADSL as a part of the entire telephone network. 

SUMMARY OF THE INVENTION 

[0015] The present invention is directed to a system and method for assimilating 

information from disparate information sources. More specifically, the present 
invention taps into sub-components of several telecommunications systems, including 
but not limited to LEIS and CBM (a backup mechanism for TIRKS available fi-om 
CBM Information Systems, Little Rock, AR,), and extracts selected pieces of 
information so that telecommunications equipment in the local loop can be organized 
by wire center and location and so that information concerning usage data of 
equipment slots and ports can be easily examined or compared to one another. 

[0016] A goal of the present invention is to present the extracted and assimilated data 

to a user via a graphical user interface and/or world wide web interface. 

[001 7] At a very high-level, the process in accordance with the present invention 

comprises extracting data firom certain tables in LEIM and LEAD (sub-components 
of LEIS) and CBM porting the data over to an Oracle database, performing data 
summary routines, and presenting the data through a graphical user interface. In a 
preferred embodiment, temporary tables are provided in which the summary routines 
are performed. Separate tables are populated to support the graphical user interface. 

[001 8] The present invention, also referred to herein as Facility Assignment Specialist 

(FAS), addresses the following fiindamental problems: determining the availability of 
DS-rs at on-premises muxes, making that information available to customers, 
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comparing data from several systems and planning and analyzing information from 
the several databases and information sources. 
[001 9] In this regard the present invention provides: 

1) a means for determining the availability of certain services (e.g., DS-1 services) at 
select locations and making that availability information known to a particular set of 
wholesale customers, thereby allowing those wholesale customers to order these 
services and have them installed in a shorter period of time than they would otherwise 
be possible. 

2) graphical presentation of data (iView) 

3) comparison of LEAD and LEIM data for DS 1 ports (iView) 

4) a means of comparing that data residing in, for example, LF ACS/LEAD, LEIM, 
and TIRKS databases and presenting it to a user as needed. 

5) A simple GUI for running reports based off of LEAD data to determine cross box 
and RT site exhaust and utilization. 

6) Tools for creating, storing, and publishing relief plans. 

[0020] ASIP (automated short-interval provisioning) functionality, which is 

preferably employed as the means for determining the availability of certain services, 
arose out of a need to improve service to wholesale (or access) customers. Access 
customers are willing to pay more for a service if they can receive a guarantee that the 
service will be available by a certain date. Many access customers desire service at 
locations where service (typically DS-l/Tl) is readily available. RBOCs therefore 
need a means of monitoring those locations, determine which locations have available 
capacity, and presenting that information to the customer service representatives who 
serve the access customers in a manner which does not unnecessarily burden the 
customer service representatives. 
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[0021] Using the present invention, planners, i.e., LCMs and others, can view Central 

Office (CO) or individual Remote Terminal (RT) information including: 

Location Information: 

General ( address. Alarm Wiring Figure - AWF, when it was placed, etc.) 

MUX capacity (Tls a available, Tls working, total Tls) 

ADSL capacity (available, working, total) 

Individual pieces of equipment at the location 
Equipment Information (All fields from Equipment table in LEIM) 

Equipment IDs 

Bay, Unit 

SCIDs, TIDs 

HECI Codes 
Slot information 

Circuit Identifier Information from each application (LEAD, TIRKS) 
System Information 

[0022] In addition, color-coded capacity indicators displayed in the GUI simplifies 

identifying "trouble spots". Also, for muxes, the present invention provides easy 
navigation to other nodes within a ring topology. Still further, the present invention 
preferably incorporates pictures of individual Remote Terminals, including 
casements, cabinets, equipment and cards for equipment, whereby a visual cue of the 
equipment can aid a LCM to recall the type of equipment for which data is being 
displayed. 

[0023] It is therefore an object of the present invention to provide a system and 

method for assimilating information from several databases to provide usefixl analytic 
tools for telephone network managers. 



[0024] It is also an object of the present invention to provide a system and method for 

providing an intuitive graphical user interface that presents information about 

telecommunications equipment, slots, and locations is an intuitive fashion. 
[0025] It is also an object of the present invention to provide a system and method for 

extracting telecommunications information conceming the local loop and the 

interoffice connections from legacy computer databases and systems and porting the 

extracted information to a user-friendly environment. 
[0026] It is still a further object of the present invention to provide a system and 

method for providing information about the outside plant of a telephone network that 

is arranged, at least initially, by wire center. 
[0027] It is also an object of the present invention to provide a system and method for 

providing local loop managers with tools to manage the various telecommunications 

facilities for which they are responsible. 
[0028] It is also an object of the present invention to provide a system and method for 

determining which locations have sufficient facilities available for particular service 

types and, upon a request for service from certain customers, retum to the user 

information as to the availability of that service. 
[0029] These and other objects of the present invention will become apparent upon a 

reading of the following detailed description in conjunction with the associated 

drawings. 



BRIEF DESCRIPTION OF THE DRAWINGS 

[0030] Figure 1 is a schematic diagram of a conventional telephone network. 

[0031] Figure 2 is a schematic diagram of how a regional bell operating company 

(RBOC) can be broken down. 
[0032] Figure 3 is a schematic diagram of an exemplary data extraction process in 

accordance with the present invention. 
[0033] Figures 4-12 depict the relevant LEIS tables, variable fields and sizes of fields 

to the present invention. 
[0034] Figures 13-15 depict possible deployment configurations of muxes that are 

accounted for by the present invention. 
[0035] Figure 16 shows the relationship among the temporary tables that are 

employed by the present invention. 
[0036] Figures 17-25 respectively depict preferred formats for each of the temporary 

tables in accordance with the present invention. 
[0037] Figure 26 shows the relationship between another set of tables used to 

assimilate information from the several temporary tables in accordance with the 

present invention. 

[0038] Figures 27-3 1 depict each of the tables shown in Figure 26 in more detail. 

[0039] Figures 32-36 illustrate how each of the tables of Figures 27-31 are populated 

in accordance with the present invention. 
[0040] Figures 37-41 show tables used for implementing the several data views 

contemplated by the present invention. 
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Figures 42-47 illustrate exemplary graphical user interface display screens in 
accordance with the present invention. 

Figure 48 demonstrates a particular application of TIRKS processing in 
accordance with the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

The present invention will now be described in the greater detail using 
BellSouth Telephone (BST) as specific example. However, those skilled in the art 
will appreciate that the present invention is applicable to any regional bell operating 
company (RBOC), local exchange carrier (LEG) or competing LEG (GLEG) or any 
other telecommunications service provider that needs to manage telecommunications 
facilities. The present invention comprises several components that are aggregated to 
provide meaningful information to a loop capacity manager (LGM). In a preferred 
embodiment of the present invention, a user fiiendly graphical user interface (GUI) is 
made available to a user. This GUI and underlying systems and methods is 
sometimes referred to herein as "iView" (Inventory View), which is an actual 
implementation of the present invention. 

The following description is divided into the following sections: 

L Overview - A brief overview of the areas within BellSouth affected by iView. 

2. LEIS Requirements - This section describes the requirements needed to gather 
data from the LEIS database. 

3. Interface Specifications - This section explains the interface between the LEIS 
system and the Oracle database which provides the data for iView. 
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4. Oracle Requirements - This section reviews the database structure needed to 
power iView including size and structure of the tables, views, and the business 
rules for the underlying data source. 

5. iView Graphical User Interface - This section describes the iView GUI 
functionality and what information is conveyed to the user, 

6. TIRKS matching - This section describes how data in TIRKS, CBM and LEIM 
and LEAD is reconciled 

7. Crossbox tracking - This section describes tracking feeder-distribution interfaces 
(FDL 

L OVERVIEW 

[0045] The present invention is mainly concerned with the part of the LEG (Local 

Exchange Carrier) telephone network that is physically located outside of telephone 
company buildings. This includes cables, conduits, poles and other supporting 
structures and certain equipment. Generally speaking, outside plant includes the local 
loops from the EEC's switching centers to the customers' premises, and all facilities 
which serve to interconnect the various switches (e.g., central office and tandem) in 
the carrier's intemal network. Dedicated outside plant comprises local loop facilities 
which are dedicated from the switching center to the customer's premises. 

BST Hierarchy 

[0046] Referring to Figure 2, Bellsouth's network is (as are other typical telephone 

networks) divided into logical areas and sub-categories therein. The hierarchy is: 

• 9-state BellSouth region (Alabama, Florida, Georgia, Kentucky, Louisiana, 
Mississippi, North Carolina, South Carolina, Tennessee) 
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• The 9-state region is broken down into state/NVP (Network Vice President). 
These areas are geographically divided by each state with the exception of 
Florida which is divided into North Florida and South Florida. 

• Each state is broken down into districts. There are a total of 38 districts in 
BellSouth. 

• Each district is broken down into wirecenters. There are approximatelyof 1 600 
wirecenters in BellSouth. 

• Each wirecenter is broken down by location. One location is the central office 

(CO), which supplies service to remote terminals (RTs). The relationship 
between locations is one CO to many RTs 

• At each location, there is equipment. 

• Certain pieces of equipment can be further broken down into slots. 

Planning and Provisioning 
[0047] The planning and provisioning process is handled primarily by a group of 

LCMs. As previously explained, the LCMs' responsibilities include (but are not 
limited to): 

• Planning and providing facilities (circuits, equipment, capacity) for service to 
potential customers within a given wirecenter; 

• Maintaining knowledge of equipment inventory and technology of that equipment 
within an assigned wirecenter; and 

• Budgeting and forecasting for their wirecenter. 

Databases 

[0048] Much of the data that LCMs use in their day-to-day planning is kept up in 

various databases. They use this data to run reports and analyze possible trouble 
areas or potential growth areas. One system of databases is the well-known LEIS 
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(Loop Electronic Inventory System) system, available from Telcordia, Morristown, 
NJ. The LEIS system is a versatile decision support system that is used by field and 
staff engineering operations for the daily planning and design of the outside plant 
network. It is a software system that uses the UNIX S VR4 operating system and the 
Ingres 6 database manager which allows the user to create programs and to 
manipulate data to custom build reports based on specific planning and design needs. 
Within LEIS are two large databases known as LEIM (Loop Electronic Inventory 
Module) and LEAD (Loop Engineering Assignment Data). 

[0049] LEIM is a module of the LEIS System used to inventory Loop Electronics 

(LE) sites, equipment, plug-ins, connections and systems. The LEIM module contains 
data related to digital loop carriers (DLC), loop multiplexers (MUX), optical fiber 
systems and other loop electronics. It shares data with other LEIS application 
modules in order to produce administrative reports, inventory reports, utilization 
reports, and to support the design, planning, budgeting, ordering, and forecasting of 
loop electronics equipment. 

[0050] The Loop Engineering Assignment Data (LEAD) module of the LEIS system 

is used by the outside plant engineer to support the planning and design of the local 
loop. The Loop Facilities Assignment and Control System (LFACS) is the component 
of the Facility Assignment and Control System (FACS) that inventories outside plant 
facilities and provides mechanized assignment capabilities for those facilities. The 
LEAD database is created or refreshed by taking an extract from LFACS and loading 
it into LEAD to create a relational database. Software extracts data from LFACS on a 
wire center basis and passes the data to LEAD, 



13 



LEIS REQUIREMENTS 



A significant function of the present invention, or iView, is to provide data to 
the users (namely LCM and managers) from LEIS databases, LEIM and LEAD. 
Although LEIM and LEAD are excellent for storing the data, as legacy systems, they 
are not particularly user-friendly. iView provides the necessary routines and "back 
office" functionality necessary to provide relevant data in a "point-and-click" user- 
fnendlyGUI. 

Data Extract 

Referring to Figure 3, a data extract script is placed in the /apl/local/leim/bin 
directory on one or more LEIS machines. The script extracts data from nine tables 
(described below), compresses the data into nine flat files, tars the nine files into one 
file (i.e., uses the "tape archive" command in UNIX to obtain a desired data format) 
and then FTPs the data to an Oracle Unix machine, which runs various stored 
procedures, which are explained in more detail later herein. In a preferred 
implementation, the script is placed in a cron and run automatically. A client 
machine, running the Microsoft Windows operating system, accesses the Oracle Unix 
machine using the well-known Open Database Connectivity (ODBC) protocol. An 
attachment to this docximent demonstrates another means of performing this task by 
connection directly to the LEIS machines. 

The tables that data is extracted from comprise: Connection, Equipment, 
I__Sysconn, Location, Slot, Support_Pair, and System from the LEIM database and 
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Pair and Loop from the LEAD database. Only a few fields of data are selected from 
the Pair and Loop tables and all fields are selected from the remaining tables. An 
additional Wirecenter (wc) field is appended to each record on every table. This 
Wirecenter field serves as a major identifier for records in the Oracle database. 
Figures 4-12 depict the tables, variable fields and sizes (according to the LEIS 
system), and descriptions of each field that is extracted for the purpose of running 
iView. 



3. Interface Specifications 

[0054] This section describes the interaction from the tables in LEIS and the Oracle 

database where iView receives its data. Mainly, the interface specifications describe 
the file(s) of extracted data (size, records, nomenclature, etc.). The first step is to 
extract the data from the tables shown in Figures 4-12. This data is preferably 
packaged into pipe-delimited ("|") flat files which have the following nomenclature: 
Iview.wctrcUi.tablename 

[0055] The flat files are published to a directory on the LEIS machine ("/tmp') where 

the following steps occur. The flat files are compressed (using: compress filename) 
and have the following structure: Iview.wctrcUi.tablename.Z 

[0056] The compress command automatically adds the .Z extension. Afl;er being 

compressed, they are then "tarred'' (tar cyfV ileToCompressInto 
FileThatlsBeingCompressed) and have the following name: iview.wctrcUi.tar 

[0057] After being tarred, the tar file is transferred via File Transfer Protocol (FTP) to 

the Oracle file server (a machine running the UNIX OS). The path that the files are 
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transferred into (on the Oracle UNIX machine) is /bto/appl/fas/iview. Once in the 
Oracle UNIX environment, steps are taken to unpackage the flat files. 

[0058] The first step is for the table of contents for the tar file to check for all nine 

files. Once the check for the files is complete, the tar file untars and then 
uncompresses. At this point, every file is preferably stored in a directory to load into 
the Oracle database tables. 

[0059] The table below shows an exemplary maximum number of records that are 

loaded into the Oracle database at any given time, based on the assumption that six 
wirecenters worth of data will be loaded consecutively during this process. In an 
actual implementation of the present invention, the total maximum number of records 
loaded onto the server at one time is approximately 6,591,960. Of course, this 
number will change depending on the implementation. 



Table Total Records 

Connection 454,291 

Equipment 6,188 

I Sysconn 167,614 

Location 636 

Loop 8,257 

Pair 67,093 

Slot 390,280 

Support_Pair 2,5 1 1 

System 1,790 

Total 1,098,660 

Six cons. 6,591,960 
WC 



4. ORACLE DATABASE REQUIREMENTS 
Business Rules 
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[0060] There are "batches" of updates that preferably occur on the database. In a 

preferred embodiment all the data is loaded into temp tables, which are replicas of the 
master LEIM tables. Therefore, nine temp tables (tmpJTablename) are set up for 
SQL Loader scripts to load the data into. Once the data is loaded into the temp tables, 
the following batches of stored procedures preferably occur: 

L Update Cable information in the Slot table (both CO and RT equipment) 

2. Update PG Pair information in the Equipment table. 

3. Update Test Pair information in the Equipment table. 

4. Update ADSL information in the Slot table. 

5. Update Tl information in the slot table. 

6. Delete the old data for a particular wire center from the master tables and replace 

it with the updated data from the temp tables and procedures. 

7. Remove the data from the temp tables. 

[006 1 ] Stored procedures are preferably created based on the following business 

rules. Six extra fields are added to the Location table for update by the stored 
procedures, namely, availableTls, activeTls, muxcap, adslcap, adslavail, and 
adslwkg. 

Tl Update 

[0062] Tl summary information is gathered from the cables, which are appended to 

the slot table's data. (Md stands for multiplexer derived, thus cable names which 
begin with md originate at a multiplexer.) To understand the counting method, the 
following is a brief synopsis of naming conventions and practices. 

[0063] There are two main configurations for muxes (or muldems) in the field. They 

can either be asynchronous muxes or SONET muxes. Asynchronous muxes are on a 
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point-to-point topology; for every md cable in the CO, there is only one 
corresponding md cable at an RT. Therefore, in terms of a naming convention, the 
CO and RT can share one md cable name. All md cables appear in the connection 
table. For example, a CO mux is named coddmlOOO#0001 with md cable mdal234. 
Based on this naming convention, the RT site where the corresponding mux is has to 
be rtl234a. The RT mux will be named something like rtl234addml000#0001 and 
should have md cable named mdal234 as well. See Figure 13. 

[0064] It should be noted that some SONET muxes can be built in as asynchronous 

muxes on a point-to-point configuration. The same rules apply to these muxes 
(sharing an md cable name) and should be treated as asynchronous muxes. 

[0065] SONET muxes use a ring topology. This means that for every CO mux, there 

is one or more corresponding RT mux. The md cable name for the CO mux is 
different firom the md cable name of the RTs. Referring to Figure 14 as an example, a 
CO mux is named codm203#2010 with md cable md2010. All RT mux cable names 
have increasing numbers starting with the first one added to the ring. So the first RT 
mux added to the ring will have a name like rtl234adm203#201 1 and should have 
cable name of md201 1 . The second mux added to the ring will have a cable name of 
md2012, and so on. The general similarity between all SONET muxes is that their 
cable names are same when the last digit is trimmed (md201 *). Generally, practice 
restricts the amount of muxes on a ring to no more than 10. 

[0066] In addition to the previous example, another scenario must be taken into 

account. For 0C3+ muxes, there is a chance that multiple muxes could reside in the 
CO on the same ring. 
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Example: CO muxi: codm203#2010 with md cable: md2010 

RT mux: rtl234adm203#201 1 with md cable: md201 1 
CO mux2: codm203#2014 with md cable: md2014 

[0067] Also, there is a very good chance that multiple muxes reside at one location. 

Therefore, when calculating md availability, capacity and working, ALL muxes must 

be taken into account for that site. See Figure 15. 
[0068] Noting the previous two examples, in calculating the Tls, the following rules 

are obtained: 

[0069] Tl mux capacity is the count of mux ports that have md cables associated with 

them at a given location (a distinct locid in the location table). 

[0070] Tls working are the count of how many circuits are currently working at a 

given location (a distinct locid in the location table). A circuit can exist in LEIM as a 
System ID or in LEAD as a Circuit ID. If either or both are present on a given port, 
count it as ONE working Tl . For asynchronous muxes, the CO and RT should have 
the same Tls working (and these circuits should be working on identical ports). For 
SONET muxes, these numbers may or may not be equal at the CO and RT. 

[007 1 ] Tls available are obtained differently depending on the type of mux. For 

asynchronous muxes, this number is the same whether the CO or RT is being 
calculated. Taking the capacity and subtracting working Tls calculates available Tls. 
For SONET muxes, the number of available Tls is dependent on the CO mux 
because an RT mux can only provision: 

a. a maximum of Tl s the CO is able to provision, or 

b. however many circuits are available at the RT - whichever is smaller. 

[0072] Example: One CO mux with three RT muxes. The CO provisions all 84 Tls 

to the three RT muxes evenly (28 each). Although each of the RT muxes still have 56 



19 



available ports, the CO mux that feeds it is exhausted and therefore the RT mux can 
not receive anymore service. 
[0073] It is noted that md cables have both a transmit and receive pair. A Tl is half 

of the total md cable and pairs for a given md. So, 168 md cable and pairs is the 
equivalent of 84 Tls (1 12 md cable and pairs equals 56 Tls). 

ADSL Update 

[0074] ADSL information is calculated from a count on the mr cables for each adsl 

piece of equipment at a given location. The mr cables can be found in the pair table 
and on the fromequip side in the connection table (with no equipment in the toequip 
side). Counting of adsl information is done as follows: 

[0075] Adsl capacity is a count of pairs for any adsl piece of equipment (has a cable 

like mr*) for a given location (a distinct locid in the location table). 

[0076] Adsl working is a count on how many mr cables are being utilized (has a 

circuit associated with it in the loop table) at a given location (a distinct locid in the 
location table). 

[0077] Adsl available is a count of capacity minus working for mr cables at any given 

location (a distinct locid in the location table). 

LETS Extract Files 

[0078] The LEIS system provides a group of 9 extract files for a wire center when 

that wire center is refreshed from LFACS on a monthly basis, for example. As 
already mentioned, these files are preferably "pipe" delimited text files extracted from 
9 LEIS tables. Each file is preferably loaded to a temporary table. Figure 16 shows 
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the relationship among the temporary tables generated. Figures 17-25 respectively 
depict preferred formats for each of the temporary tables. As can be seen, each 
temporary table has the WC CLLI Code added so that it can be used for multiple wire 
centers at the same time. The LEIM WC CLLI is used and is derived from the file 
name. 

[0079] The information stored in the temporary tables of Figures 17-25 is 

subsequently further rearranged into yet another set of tables that are associated with 
one another in accordance with Figure 26. The new set of tables is shown if Figures 
27-31 . Figures 32-36 illustrate, along with the following description, how each of the 
tables of Figures 27-3 1 are populated for purposes of the present invention. 

[0080] Referring first to Figure 32, most of the desired data is pulled directly fi-om 

the corresponding temporary table. Additional procedures determine the MUX 
capacity, DSl Availability and DSls working or assigned for each equipment 
Location, and determine the ADSL capacity, ADSL Availability and ADSLs working 
or assigned for each equipment Location. 
The following are preferred logic requirements: 

a) The Ship_City_St field in the Location table needs to be updated to 'adsl' for any 
pieces of equipment that are ADSL. 

b) Do not count any slots that have "tadm" in the Function column of the SLOT 
table. These are special circuits (usually on a muldem that is DS3) and do not 
count in Tl capacity. 

c) Count of ADSL is not done in the Slot table. Based on the model that LEIM uses, 
there is only one slot for every four circuits (and therefore counting circuits in the 
slot table is not valid). In other words, a mini-ram has two low speed slots, but 
eight available circuits for provisioning (capacity). 
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STEP 1: 

For each row in the LOCATION table for WC_CLLI being processed: 
Set Counters = 0 

Select all rows from EQUIPMENT where EQUIPMENT.locationJd = 
LOCATION.locationJd 

For each row selected in the EQUIPMENT table: 

Update LOCATION.Ship City St to 'adsl' where Equipid like 
'%anir08%', '%amr48%', '%ad096%', '%adl44%', or '%adl92%' 

Select all rows from SLOT where SLOT.equipment id = 
EQUIPMENT.equipmentJd 

For each row from SLOT selected, count the following: 
IfSLOT.cablelike"md%" 

Then If SLOT, function o "tadm" 

Counter_MUXcap = CounterMUXcap + 1 
IfTlStatus = l 

Then Counter_ActiveTls = Counter_ActiveTls + 1 
Else 

Else 

Else if SLOT.cable like "mr%" 
Then 

Select all rows in the TMP_CONNECTION table where 

TMP_CONNECTION.cable = SLOT.cable 

For each row from TMP_CONNECTION selected, count the 

following: 

Counter_ ADSLcap - Counter_ ADSLcap + 1 
If TMP LOOP.Loop is not null where 
TMP_LOOP.LoopID = TMP PAIR.LoopID (where 
TMP_PAIR.Cable = CONNECTION.Cable AND 
TMP_PAIR.pair = CONNECTION.pair) 
Then Counter_ADSLwkg = CounterADSLwkg + 1 
Else 

Next TMP_CONNECTION 
Else 
Next SLOT 
Next EQUIPMENT 
Set LOCATION.muxcap = CounterMUXcap 
Set LOCATION.activetls = CounterActiveTls 
Set LOCATION.availabletls = muxcap - activetls 
Set LOCATION.adslcap = Counter_ ADSLcap 
Set LOCATION.adslwkg = Counter_ADSLwkg 
Set LOCATION.adslavail = adslcap - adslwkg 
Next LOCATION 

STEP 2: 
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Now that values have been recorded for all LOCATION entries in the wire center, the 
DSl Availability has to be checked for SONET rings. The Availability on the ring may 
be limited by the Availability in the CO. If that is the case, the Availability at the RT 
Locations must be updated to be that of the CO. To do this, the MUXes on a ring must 
be identified and tagged as CO or RT. Then the Availability at the RT Location must be 
limited to the Availability at the CO Location. The MD Cable name is used to determine 
MUXes on the same ring and the LEIM Equipment ID is used to determine whether it is 
a CO or RT MUX. Therefore the logical process is to: 

• Identify all non-CO Locations. 

• For each non-CO location determine each Ring 

• For each Ring determine its CO counterpart(s) and sum CO Availability for a 
Location 

• Then limit Location Availability based on CO sum. 

For each row in the LOCATION table for WC_CLLI being processed: 
Set Counters = 0 

Get a list of MUXes (Cable) via join from LOCATION to EQUIPMENT based 
on LocationJD and EQUIPMENT to SLOT based on Distinct EquipmentJD and 
Cable where Cable like "md%" and length = 6 and Equipid not Uke "co%". 

For each Cable select list of SLOT rows where SLOT.equipid like "co%" 
and SLOT. cable like (first 5 characters of Cable fi:om list) [ex: 
SLOT.cable like "md201%" would get md2010 and maybe md2014] 
For each row fi:'om SLOT selected, count the following: 
Coimter_MUXcap = Counter_MUXcap + 1 
IfTlStatus=l 

Then Covinter_ActiveTls = Counter_ActiveTls + 1 

Next SLOT 
Next Cable 

Counter Avail =^ Counter_MUXcap - Counter_ActiveTls 
If LOCATION.availabletls is greater than Counter Avail 
Then set LOCATION.availabletls = Counter Avail 
Next LOCATION 

[008 1 ] In the foregoing procedure it is assumed that Synchronous MUX rings always 

have a 6 character cable name in format: aannnn. 
[0082] Figure 33 is populated as shown with the following qualifications: 



1 . LocationJD fi-om LOCATION where EQUIPMENT.wc_clli = 
LOCATION.wc_clK and EQUIPMENT.locid = LOCATION.locid. 



2. This column is populated only on rows where CATEGORY = 'RT'. 
Logic to populate: 
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Select CABLE and PAIR from TMP_CONNECTION where 
TMP_CONNECTION.wc_clli = EQUIPMENT.wc_clli and 
TMP_CONNECTION.fromequip = EQUIPMENT.equipid 
and TMP_CONNECTION.cable like "pg%". 
This will return multiple rows. 

Select the lowest numeric Pair (lopr) and the highest numeric Pair (hipr). 
Concatenate into a string = (cable):(space)(lopr)-(hipr) and insert into PGP AIRS. 

3. This column is to be populated only on rows where CATEGORY = 'RT'. 
Logic to populate: 

Select CABLE and PAIR from TMP_ SUPPORT_PAIR where TMP_ 
SUPPORT ? AIR.wc_cUi = EQUIPMENT.wc cUi and TMP_ 
SUPPORTPAIR-Equipid = EQUIPMENT.Equipid. 
This may return multiple rows. If so select the first Cable and Pair returned. 
Concatenate into a string = (cable):(space)(pair) and insert into TESTPAIRS. 

[0083] Figure 34 is populated as shown with the following quaUfications: 

1 . EquipmentJD from EQUIPMENT where SLOT.wc_clli = EQUIPMENT. wc_cm 
and SLOT.equipid = EQUIPMENT.equipid. 

2. Repeat step two twice— once for FROMEQUIP and once for TOEQUIP 

Update SLOT where TMP_CONNECTION.wc_clli = SLOT.wc cUi and 
TMP CONNECTION.fromequip = SLOT.equipid and 
TMP_CONNECTION.fromshelf = SLOT.shelf and 
TMP_CONNECTION.fromslotlo = SLOT.slot 
and TMP_CONNECTION.cable like 'm%' 

Set SLOT.cable = TMP_CONNECTION.cable, SLOT.lowpair = lowest numeric 
TMP_CONNECTION.pair, SLOT.hipair = highest numeric 
TMP_CONNECTION.pair. 
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Update SLOT where TMP_CONNECTION.wc_clli = SLOT.wc cUi and 
TMP_CONNECTION.toequip = SLOT.equipid and TMPCONNECTION.toshelf - 
SLOT.shelf and TMP_CONNECTION.toslotlo = SLOT.slot 
and TMP_CONNECTION.cable like 'm%' 

Set SLOT.cable = TMP CONNECTION. cable, SLOT.lowpair = lowest numeric 
TMP CONNECTION.pair, SLOT.hipair = highest numeric 
TMP_CONNECTION.pair. 

Note: "md" cables will have 2 pairs for each Slot. Example, MD2020, pairs 1 and 2. 
This process adds the Cable, Lowpair, and Highpair to the SLOT table from the 
TMP_Connection table. The other type of "m%" cable is an "mr" cable for ADSL. 
These will only have 1 pair. 

3. After Cable and Pairs are populated, then load Circuitid and Terminal from 
TMP_LOOP table. 

Join SLOT to TMP PAIR where SLOT.wc cUi = TMP_PAIR.wc_clli and 
SLOT.cable = TMP_PAIR.ca and SLOT.lowpair = TMP_PAIR.pr and then join 
TMP PAIR to TMP LOOP where TMP_PAIR.wc_clli = TMP_LOOP.wc_clli and 
TMP PAIR-loopid = TMP LOOP.loopid. Update SLOT.circuitid = 
TMP_LOOP.loop and SLOT.terminal = TMP_LOOP.term. 

4. SYSTEMID is populated from the TMP_SYSCONN table. 

Select CONNID from TMP_CONNECTION where TMP_CONNECTION.wc_clli = 
SLOT.wc_cIli and TMP_CONNECTION,fromequip = SLOT.equipid and 
TMP_CONNECTION.fromshelf = SLOT.shelf and 

TMP_CONNECTION.fromslotlo = SLOT.slot and TMP_CONNECTION.cable like 
'm%'. 

Update SLOT.systemid = TMP_SYSCONN.sysid where TMP_SYSCONN.connid = 
selected CONNID and TMP SYSCONN.wc clli = SLOT.wc cUi. 
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The above system information is partially incorrect for DISCS systems. DISCS 
systems have both an Fl AND F2 system number (at a RT). The system number in 
the Slot table has already been updated with the Fl system number, and now needs 
to be updated with the F2 system number so that the information is presented 
correctly in iView. Another query on the System table must be done to update the 
Slot table. The logic behind it is that you must retrieve the F2 System based on the 
Equipid for the Fl system: 

Select all SystemlDs from TMP SYSTEM where TMP SYSTEM.origEquip - 
TMP_SYSTEM.termequip. 

Update the Slot table with TMP SYSTEM.SysID where SLOT.SystemID = 
SYSTEM.SysID 

5. After completing the above for a SLOT row, if either CIRCUITID and/or 
SYSTEMID are populated, 
set Tl STATUS = L 

[0084] It is assumed in the foregoing that the 'mr' cables are added to the slot table 

for display, but can not be used for any sort of counting. 

5. GRAPHICAL USER INTERFACE (GUI) 
[0085] A significant aspect of the present invention is an inventory viewing (iView) 

tool which provides inventory and capacity information as it pertains to outside plant 
networks. iView consolidates information found in the LEIM and LEAD databases 
to provide a single source of information. 
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[0086] The GUI of the present invention preferably comprises five views which are 

shown in Figures 37-41. The naming convention for 4 of the views preferably is 
V_{wctrclli}_{tablename} where {wctrclli} is the LEIM Wire Center CLLI Code. 

[0087] IView provides point and click functionality either in a Windows-like 

environment or through a web browser. Planners are then able to view Central Office 
or individual Remote Terminal information including: 

• Location Information: 

a. General (address, Alarm Wiring Figure - AWF, when it was placed, etc.) 

b. Mux Capacity (Tls available, Tls working, total Tls) 

c. ADSL Capacity (available, working, total) 

d. Individual pieces of equipment at the location 

• Equipment Information (All fields fi:om Equipment table in LEIM) 

a. Equipment IDs 

b. Bay, Unit 

c. SCIDs,TIDs 

d. HECI Codes 

• Slot Information 

• Circuit Information 

• System Information 

• Color-coded capacity indicators make it easier for a quick view to possible "trouble 
spots". 

• For muxes, iView provides easy navigation to other nodes within a ring topology. 

• iView also preferably incorporates pictures of individual Remote Terminals, including 
casements, cabinets, equipment and cards for equipment. Easy sorting of information is 
applicable by each of the field names. 

[0088] When the program is first opened, a prompt asks the user to select a district 

(see Figure 2). This step provides information for setting up the link to the proper 

databases in a particular district. After selecting a district (or any time iView is 

opened, thereafter), an initial screen, as shown in Figure 42, is the graphical user 

interface (GUI) for iView. 
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Multiple Screens 

[0089] iView can also be viewed in multiple instances as shown in Figure 43. If 

different location information needs to be compared within a wire center ~ or even 
different locations in different wire centers - the menu items can be used to cascade 
the windows. On the menu, the user clicks on the menu item labeled Window, and 
next clicks on the menu item labeled New Window, Another instance of the iView 
GUI should open. The two instances of i View will tile according to the menu item 
chosen. If need be, iView can even be opened with a third (forth, fifth, and so on) 
instance. 

Initial Screen 

Referring to Figure 42, when first opening the application, on the left-hand 
side of the screen, a list of available Wire Centers (WC) in the selected district will be 
shown. Above that will be a legend for mux capacity information (explained later). 
To the right, various list boxes are shown which are explained in the following 
sections. 

Location Information 

[01 00] The user clicks on one of the RTs. The list boxes at the top and the list box on 

the right-hand side of the screen fill up with information. For ADSL and Tl 
information, the program takes a combination of all respective pieces of equipment. 
The list boxes at the top provide the following information: 
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[0090] 



[0101] General Site Information - CUi, Address, Enclosure, CSA, Plat, Geocode, 

Taxcode, Phone Number, Power, Powerout, AWF, Structure Date, Inventory Date, 
Taper Code. 

[0102] ADSL Information - ADSL capacity (Total amount of ADSL lines which can 

be provisioned at the site), ADSL working (Total ADSL lines currently working at 
the site), ADSL available (Total amount of ADSL lines available after calculating the 
capacity minus the working). 

[0103] Mux Information-Total Tls working at the site, Additional Tls available (this 

number is based on how many Tl s are available on the CO mux. In a ring topology, 
you can only have as many Tl s as are available at the CO), and the Total Tl 
Capacity. See Figure 43. 
Equipment Information 

[0104] In the main box in the screen there is a listing of individual pieces of 

equipment. The following information is available as indicated by the field names on 
the top of the list box: 

[0105] Equipment, Category, Bay, (Bay) Unit, Product ID, Generic, Account, 

Voltage, Low BitRate, High BitRate, TEO, Status, Install Date, Mode, Remarks, 
SCID, Clei, EWO, Route, Settings, PG Pairs, Test Pairs. See Figure 44A. 

[0106] If the user clicks on any one of these field names, the equipment will be sorted 

in ascending order for that particular field (e.g. click on the "category" field and all 
the equipment will be sorted in ascending order according to the type of equipment ~ 
see Figure 44B). 
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Slot Information 

[01 07] While the equipment table is open, the slot information for any piece of 

equipment (if slot information exists) can be viewed by double-clicking on that 
equipment. For example, by double-clicking on one of the muxes at an RT, 
information about that particular mux will come up including: Equipment, Port, Card, 
Function, Cable, LoPair, HiPair, Circuit ID, System ID, Terminal, EWO, Status, Clei, 
Settings, Resistance, Rate, Max Lines, Frame Space Format, Line Code, Error Rate, 
Super Slot. Some of this information is in the slot table in LEIM, but other 
information (like Circuit and System ID) is not. In addition to a graphic view of the 
slot table, there is information about the circuits and systems working on that mux. 
Figure 45 shows this feature of the present invention. 

Color Codes 

[0108] Some of the locations have a colored background and some also have a "DSL" 

logo to the left with colored backgroxxnds. This is mux capacity and ADSL 
information. The legend shown in Figure 46 explains what each color means, 
whereby it is possible quickly gauge capacity. For instance, an RT may have a red 
background. This means 80 to 100 percent of the Tls at that RT are being used and 
action should be taken to alleviate the problem. The user may also be given the 
ability to modify the color codes according to his own preference. 

[0109] Another example may be that there is a "DSL" logo to the left of an RT with a 

cyan (light blue) background to it. The cyan indicates that anywhere between 21 and 
40 percent of the ADSL being used. Essentially, the ADSL equipment is not nearing 
capacity. 
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Navigating to Other Muxes 
[0110] Some added bit of functionality includes a quick navigation to any other mux 

within the either a point-to-point or ring topology. Right-clicking one of these muxes 
will bring up a menu listing all other muxes within that network. By highUghting a 
mux with the mouse and right-clicking on it, iView takes you to that location. Figure 
47 illustrates this feature of the present invention. 

Pictures 

[0111] Another feature provided by iView is the ability to look at actual pictures of a 

site. These digitized photos have been incorporated into the setup program itself and 
allows the user to view different attributes about the site. In a preferred embodiment, 
there are photos of casements, cabinets, and individual pieces of equipment. A 
picture is loaded into the top right panel of the main screen shown in Figure 42. In a 
preferred implementation, it is possible to enlarge the picture for more clear viewing. 
6. TIRKS MATCHING 

[01 12] To uniquely identify a device in TIRKS, the following pieces of data are 

required from LEIM. 

o Loc CLLI: the unique identifier for a location 

o Bay: the physical location on a 7 foot equipment rack 

[0113] To uniquely identify a device in LEIM, one data element is required 

o Equip_ID: unique identifier in for a device 
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[0114] The first step in connecting LEIM data to TIRKS data is to select the SCID, 

the LOC CLLI5 and the Bay firom LFACS. In iView, this data is stored in the 
following manner: 

o SCID: stored with column name Tilter' in the IV_EQUIPMENT table in lower 
case 

o LOC__CLLI: stored with column name 'cUi' in the IV LOCATION table as 
lower case. This data is found for a device by joining IV EQUIPMENT to 
IV LOCATION using the 'location id' column 

o BAY: stored as BAY in the IV EQUIPMENT table as lower case 



[0115] Next, use these three data elements to select the TIRKS data. The data is 

stored in CBM as follows: 

o SCID: stored as 'SCID' in the CBM_LOW__SIDE table as upper case 

o LOC CLLI: stored as 'NODE ' in the CBM_LOW_SIDE table in upper case 

o BAY: stored as 'EAST_RACK' or 'WEST_RACK' in the CBM_NODES table. 
Found by joining the CBM LOW SIDE and CBM_NODES tables using SCID 
and NODE 

Sample Queries for wire center FTLDFLCY 
Gather LFACS data: 

select a.equipid, a. bay, a. filter, b.clli, c.CIRCUITID, c. shelf, c, CABLE 

C.LOWPAIR, c.HIGHPAIR, c.SYSTEMID, C . SLOT 

FROM iv_equipment a, iv_location b, iv_slot c 

WHERE a.wctrclli - 'FTLDFLCY' and 

a. category = 'mux' and 

a. filter is not null and 

a . L0CATION_ID = b. location_id and 

a. equipment_id - c. equipTnent_id and 

c.circuitid is not null and rownum <=500; 

Select data from CBM: 



select a.scid, a. node Loc_Clli, a.hcode, a. unit, a.cktid, a. act, a. frame 

a. bay, a. panel, a. jack, b.EAST_RACK, 

b. west_rack, b. system, b. facility, b.act 
from low_side a, nodes b 

where a.scid in { 'NE86CL^ 'NE26BL' , 'NE26CL' ) and a. node = 'FTLDFLCY' and 
{b.east_rack in (' 01141 . OOA' 01141 . OOB ' , 
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^01141. OOC , '01141, OOD' } or b.west_rack in 

( ' 01141 .0 OA' , ' 01141. GOB' , ' 01141.00C' , ' 01141. GOD' } ) 

and b.scid = a.scid and 

b.node = a. node 

and a.cktid is not null and rownum <=500; 



[01 16] The following process enters data into TIRKS based on the LFACS data to 

ensure that the data is consistent 

o LCM determines what equipment to place 

o Hands this requirement for placing equipment to a designer 

o The designer enters the information into LFACS or sends to a LFACS expert to 
enter into LFACS 

o The output from the process are forms to order plugs, place the device, and to tell 
the technicians what to connect 

o MECEIU is then run to feed the data to TIRKS 

[0117] To identify the slots on a MUX add the HCODE (HCCI) to the three data 

elements 
o SCID 
o LOC^CLLI 
o BAY 

o HCODE: identifies whether DS 1 or DS3 

[0118] To identify the muldem or Circuit ID, add Unit to the four data elements 

o SCID 

o LOC_CLLI 

o BAY 

o HCODE 

o UNIT 
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There is a need to match equipment data from CBM (source database is 
TIRKS) with equipment data from LEIM. The problem is that users currently have to 
log into both TIRKS, LEIM, and LEAD to pull usage information concerning a piece 
of equipment. Many users avoid using TIRKS, as it is notoriously difficult to use. 
Furthermore, by providing this data is an easy to use manner, then database clean up 
is more efficient. 

First the tool should match the pieces of equipment from each of the two 
systems. This is done by matching the CLLI (the Common Language Location 
Identifier as determined by Telcordia) and BAY location for each system. Once the 
equipment is matched, then the UNITs (in the form of Muldem, slot, port) for each 
piece of equipment are matched. Circuit information such as circuit identifier and 
status can then be matched for each database. Figure 48 demonstrates a particular 
application of this logic. The SCID (SONET Carrier IDentifier) is not required, but 
may be employed as desired. 
7. CROSSBOX MATCHING 

One of the most important and difficult devices to monitor is the feeder- 
distribution interface (FDI,) also known as a crossbox. Figure 1 demonstrates the 
location of the crossbox in the telephone network. The original crossbox arrangement 
was such that every "feeder cable" was capable of providing every type of service, or 
at most, feeder cable was conditioned such that there were two groups of feeder cable, 
each capable of providing certain types of service. The advent of DLC and its 
introduction into the telephone network has created a situation where multiple types 
of feeder cable feed the same crossbox. 
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[0122] As DLC systems have improved over the years, the types of services which 

can be provided via these systems has been significantly expanded. Whereas the 
original capacity was 96 POTS (plain old telephone service) lines when served by 4 
DS-l's. Today, the capacity is 96 POTS lines or some combination of POTS, coin 
operated lines, ISDN, or 56kb (among other services.) The capacity is determined by 
the types of cards (or plugs) available for that type of DLC system, they number of 
DS-l's feeding that system, and the means of connecting that system to the switch 
(universal, integrated TR-08, integrated TR-303.) 

[0123] As DLC systems have improved to allow more service types, demand from 

customers for those services has increased. All current reports for a crossbox list the 
number of pairs which feed that crossbox and the number which are spare. 
Unfortunately, knowing the number of spare facilities at a crossbox does not tell an 
LCM what services can be provided and what services need more facilities. This tool 
provides a matrix as demonstrated in a simple form below: 
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Facility Type is defined as a group of facilities with like transmission 
characteristics (capable of supporting the same types of services.) For example, all 
copper pairs which have no conditioning equipment will be grouped into one facility 
type. Universal DLC such as SLC96 (manufactured by ATT,) Series 5 (manufactured 
by Lucent Technologies,) and Fujitsu Digital Loop Carrier will be grouped into a 
separate facility type. 

Service Type is defined as a types of service which require the same 
transmission characteristics. POTS service would be one service type. Special 
services such as 9kb, 16kb, 56kb, and 64kb, have very similar transmission 
characteristics, so they would be grouped to another Service Type. 

Letters a, b, and c in the above figure represent the number of circuits of 
Service Type 1 which are being served from each of the respective Facility Types. 
Letter d represents the sum of a, b, and c. Letter m is determined by determining how 
many services can be provisioned based on the number of spare (hj, k) for each 
Facility Type. 

While the current design calls for extracting data from the LEAD module in 
LEIS, this tool can be modified to use data from other sources such as TIRKS. 

This matrix should exist for every monitoring point in the network, including 
but not limited to crossboxes, DLC systems, and multiplexers. This tool can also be 
used for copper and fiber optic cables. 

This matrix is typically updated on a monthly basis. As updates are received, 
previous month's data is stored so trends can be identified. A typical storage plan 
would call for twenty- four (24) months worth of data plus one month's data from 
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each of the previous three (3) years so that data exists for five (5) years total. (For 
example, data is created for month 1. As month 2 data is created, month 1 is stored. 
This continues through month 24. On month 25, data will exist for month 1 and 
months 3 through 24. On month 37, data will exist for month 1 , month 13, and 
months 14-37.) 

[0130] Reports can then be created based on either the most current month or based 

on trends identified from the previous months' data. Scenarios can also be created 
and studied. One such scenario would allow the user to request a list of crossboxes 
that would receive a years worth of relief for a particular service type if the number of 
defects were reduced by 50 percent. 
ASIP 

[0131] There are some customers who have a multiplexer in or very near their 

building. Other customers are very close (less than 9000 feet) to a central office. 
This situation allows the phone company to provision DS-1 service for that customer 
in a shorter time frame than would usually be required for DS-1 service. BellSouth 
has called this short-interval service ASIP. 

[0132] There are several steps associated with ASIP: 

1) FAS catalogs addresses which qualify for ASIP service. On-premises 
multiplexers are determined through the following process: muxes are 
automatically presented to the LCM for validation. The LCM manually 
enterasthe address for those locations which are not served by an on-premises 
mux. BellSouth refers to this combination of an address and a particular service 
type (such as DS-1) as a service point. 
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2) For each service point, FAS confirms that the address information is in an 
acceptable BellSouth format. 

3) The path from the service point to the central office is then determined. In the 
event of an on-premises multiplexer, this path is simple and automatically 
determined. In the event of a customer which is not provisioned via an on- 
premises mux, FAS will present the likely paths to the LCM who will then select 
the path(s) which should be monitored. 

4) For each service point, FAS monitors the path(s) to determine if the number of 
services available via that path is above a set threshold. If so, then the service 
point is said to be on-net. If not, then the service point is said to be off-net. 

5) An interface is made available to customer service representatives. A customer 
service representative is able to enter an address and determine if that address is 
on-net. 

[0133] The foregoing disclosure of the preferred embodiments of the present 

invention has been presented for purposes of illustration and description. It is not 
intended to be exhaustive or to limit the invention to the precise forms disclosed. 
Many variations and modifications of the embodiments described herein will be 
obvious to one of ordinary skill in the art in light of the above disclosure. The scope 
of the invention is to be defined only by the claims appended hereto, and by their 
equivalents. 

[0134] Further, in describing representative embodiments of the present invention, 

the specification may have presented the method and/or process of the present 
invention as a particular sequence of steps. However, to the extent that the method or 
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process does not rely on the particular order of steps set forth herein, the method or 
process should not be limited to the particular sequence of steps described. As one of 
ordinary skill in the art would appreciate, other sequences of steps may be possible. 
Therefore, the particular order of the steps set forth in the specification should not be 
construed as limitations on the claims. In addition, the claims directed to the method 
and/or process of the present invention should not be limited to the performance of 
their steps in the order written, and one skilled in the art can readily appreciate that 
the sequences may be varied and still remain within the spirit and scope of the present 
invention. 
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